Relative Issue: #2020 (comment) (reported in a comment)
Relative PR: #1827

This PR enables previous_response_id chaining during internal function calls inside the first turn, even though no real previous_response_id exists yet.

Only the first turn is special-cased; once the first real response_id is obtained, all subsequent turns behave normally.

Background

Currently, previous_response_id chaining only enables when a real previous response ID is explicitly provided. This works fine for subsequent turns, but it has a limitation:

For the first turn of a brand-new conversation, there is no existing previous_response_id. As a result, there is no way to tell the SDK that internal function calls can use previous_response_id chaining.

Solution

Introduce a special flag value:

previous_response_id = "bootstrap"

Setting "bootstrap" makes the internal function calls inside the first turn use proper response chaining.

Example usage:

previous_response_id = "bootstrap"

while True:
    user_input = input()
    result = await Runner.run(
        agent,
        user_input, 
        previous_response_id=previous_response_id
    )
    previous_response_id = result.last_response_id

Alternative solution

If the "bootstrap" magic string is undesirable, an explicit parameter could be added:

previous_response_id = None

while True:
    user_input = input()
    result = await Runner.run(
        agent,
        user_input,
        previous_response_id = previous_response_id,
        enable_internal_previous_response_chaining=True,
    )    
    previous_response_id = result.last_response_id

However, this introduces an extra API parameter solely for this niche feature and feels a little verbose.
I am open to switching to this approach if preferred.